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AN EXTENSIBLE PROXY FRAMEWORK FOR E-MAIL 
AGENTS 

FIELD OF THE INVENTION 

5 The present invention relates to a proxy framework coupled between an 

electronic mail client and a network for processing electronic messages. 

Specifically, the proxy framework performs functions on behalf of the mail client 
while preserving a standardized interface to a network having electronic messaging 
capability. 

10 

BACKGROUND OF THE INVENTION 

There has recently been a massive proliferation of interconnected or 
networked computers. One of the biggest advantages of this proliferation is the 
ability of users at computers coupled to the network to exchange electronic mail or 
15 electronic messages. Existing electronic mail allows users to exchange information 
between computers connected by a modem, connected across a local area network, 
or connected across the Internet. In the latter configuration, groups of computers 
having electronic mail capability are typically coupled to the internet through an 
internet service provider (ISP) or gateway. Electronic messages can convey not 
20 only text information, but also images, sounds, motion picture with sound and 
binary files with executable programs. 

Advanced electronic mail features can significantly enhance the user’s 
experience of electronic mail by reliably and tirelessly performing mundane tasks 
associated with features like classification, filtering, encryption, authentication, and 
25 auto response. Conventionally some advanced features have been implemented as 
extensions to (or replacements for) particular e-mail client programs. However, 
implementation of advanced features within the client electronic mail software itself 
is cumbersome and inconvenient. This is because of (1) the number and diversity of 
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client software packages, (2) the fact that the code of client software packages is 
typically beyond the control of the ISPs wishing to add features uniformly to all 
clients within their service groups, and (3) the difficulty of persuading users to 
switch client software. 

5 Some advanced features have also been implemented at servers located in 

the network path between the many e-mail client programs and the remote source of 
the e-mail on the network. However, these “server-side” implementations suffer 
from either limiting the preferences of the individuals who maintain electronic mail 
capability coupled to the server, or from the impracticality of administering 
10 personalized solutions on a large scale. 

It would be desirable to implement agent-like capabilities having advanced 
functionality in the form of an e-mail proxy that operates logically between the off 
the shelf mail client, such as NETSCAPE e-mail and EUDORA e-mail, and network 
based mail servers. It would also be desirable to add advanced agent functionality 
15 arbitrarily, using a flexible, extensible proxy framework, without forcing users to 
change mail client software, server software, or any other aspect of their existing 
environment. 

SUMMARY OF THE INVENTION 

20 According to the present invention, a system for processing electronic 

messages includes an electronic mail client and a proxy application resident in a 
memory and a communications port for exchanging electronic messages with an 
electronic mail network. The proxy application has a configurable controller 
specifying a manner of routing electronic messages between the electronic mail 
25 client and the communications port. A processor within the system, coupled to the 
communications port and the memory, executes the proxy application to route 
electronic messages between the electronic mail client and the communications port 
in accordance with a configuration of the controller. 

The controller of the proxy may be configured to perform any convenient 
30 function, such as filtering or terminating electronic messages meeting a 
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predetermined criterion or generating new messages in response to receiving an 

r 

electronic message (autoresponse). In addition, the proxy may include interfaces 
that conform to standard protocols such as the simple mail transfer protocol 
(SMTP) for interfacing with the electronic mail client and a network node within the 
5 electronic mail network. Such standard interfaces facilitate integrating the proxy 
into the electronic message datapath between the mail client and the electronic mail 
network. 

BRIEF DESCRIPTION OF THE DRAWINGS 

10 The above described features and advantages of the present invention will be 

more fully appreciated with reference to the appended figures and detailed 
description. 

FIG. 1 depicts a client computer having electronic mail capability coupled to 
a plurality of other client computers over a computer network. 

15 FIG. 2 depicts a proxy framework according to the present invention. 

FIG. 3 depicts a method of receiving electronic messages according to the 
present invention. 

FIG! 4 depicts a method of transmitting an electronic message according to 
the present invention. 

20 FIG. 5 depicts a method of processing user commands according to the 

invention. 

DETAILED DESCRIPTION OF THE INVENTION 

FIG. 1 depicts a plurality of client computers 10, each possessing electronic 
25 mail capability, interconnected over a computer network 26 allowing the exchange 
of data between client computers. Computer network 26 includes a plurality of 
network nodes 24 which may be interconnected electronically, optically, or 
wirelessly. Each network node 24 may have a plurality of client computers 10 
coupled to it. Network 26 may be a local area network, a wide area network, or a 
30 network of computers operating under the Internet protocol. The network may 
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include one or more gateway nodes 28. The gateway nodes 28 translate between 
electronic mail messages in one protocol to electronic mail messages in another 
protocol used by the e-mail programs at the client computers 10 coupled to the 
gateway node 28. 

5 FIG. 1 also shows an exploded view of a client computer 10. The client 

computer 10 includes a processor 12 coupled over one or more buses 14 to a 
memory 16, a keyboard 18, a mouse, 19, a display 20, and a communications port 
22. The bus 14 enables the exchange of data between the processor 12 and each 
interconnected component. The memory 16 includes both random access memory 
10 ( RAM 3 ) and fixed memory, for example, disk drives and optical drives. The 

memory 16 includes stored program instructions for a user’s mail client 32 as well 
as stored program instructions for an electronic mail proxy 30 according to the 
present invention. The contents of the memory 16 are more fiilly described with 
reference to FIGS. 2-5. The processor 12 executes program instructions stored in 
15 the memory 16 and monitors and responds to instructions entered at the keyboard 
1 8. In addition, the processor 12 updates the display 20 according to program 
instructions. The communications port 22 allows the processor 12 to communicate 
with other client computers 10 coupled to the network 26. The communications 
port 22 is implemented as a modem, a local area network card, or similar device for 
20 signaling over a communications link. The communications port 22 may be coupled 
over a local area network such as an Ethernet or token ring network to a network 
node 24. Alternatively, the communications port 22 may be connected to an 
Internet service provider node over a telecommunications link. It is through the 
communications port 22 that the processor 12 is able to send and receive electronic 
25 mail messages with other client computers on the network 26. 

FIG. 2 shows the e-mail proxy architecture 30 and its interaction with a 
user’s mail client 32. The e-mail proxy consists of six daemon processes including 
SMTP proxy server 33, POP3 proxy server 34, POP3 proxy getter 36, SMTP proxy 1 
sender 38, user interface 40, and controller 31. The proxy 30 also includes four 
30 persistent mail queues called outgoing queue 42, deliver queue 44, incoming queue 
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46, and send queue 48. The controller 31 acts as the brain of the proxy 30, 
directing the desired proxy functionalities such as filtering, auto response, 
encryption, authentication, and classification. 

The controller 3 1 gets input from two of the four mail queues, incoming 
5 queue 46 and outgoing queue 42. Typically, the controller 3 1 will accept a message 
from one of these two queues, process it, and then place messages in one or both of 
its output queues, send queue 48 and deliver queue 44. Optionally, the controller 
3 1 may send events to a user interface 40. The behavior of the controller 3 1 may be 
customized to include advanced features to meet the needs of a particular user. 

10 The user customizes the controller at compile time (using a programming 

model “APT’ as will be described later in this disclosure) by specifying custom 
feature logic that comprises instructions for what the proxy is to do in response to 
the various incoming messages and other events it must handle. 

For example, to implement a filtering proxy, the user would specify a set of 
1 5 rules that classify incoming messages based upon syntactic criteria defined by the 

user, such as “is the sender address that of a known correspondent? Does the 
message contain the word ‘advertisement,’” or a synonym or close misspelling 
thereof? The user then surrounds these rules with procedural program steps that 
actually compute the syntactic criteria (via utility functions provided in the proxy 
20 framework, or perhaps by new utility functions coded by hand for this application) 
and then evaluate the rule predicates. The programmer includes steps that dictate if 
the predicates evaluate to true for a rule, then the action described by the rule is 
taken, such as delivering a message to the user or sending one out to the network. 

As a concrete example, suppose the user wishes to filter out all messages 
25 containing the word “advertisement” in the subject line, so that they are never 
presented by the client to the user for reading. The user would specify program 
steps to the controller 3 1 that first applied a string search utility function (supplied 
by the framework in this case) to the incoming message, searching for the string 
“advertisement”. Next, if the search result was negative, i.e. no such string was 
30 found, the feature logic would tell the proxy to place the message in the deliver 
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queue using the DELIVER act. Otherwise, if the search result was positive, it 
would dictate taking no further action; in particular, it would not place the message 
in any queue, so it would be discarded or terminated instead of being delivered to 
the client software. 

5 As another example, to implement an encrypting/decrypting proxy, the user 

would specify to the controller 31 program steps that first extract the sender of an 
incoming message from the message Jieader; next, look up the decryption key stored 
in the proxy database for that sender, next supply it, along with the encrypted 
message body to a decryption algorithm utility function (either provided by the 
10 framework or coded by hand), packaging the resulting decrypted body along with 
the original header information into a new message; and finally specifying the action 
of delivering this new message to the user. For outgoing messages, a similar 
sequence of steps could encrypt the outgoing message and send it to the intended 
recipient. 

15 As an example, suppose a user has one correspondent with whom he shares 

an encryption/decryption key pair, and this correspondent sends him an encrypted 
email message. Once this message is presented to the custom controller, the feature 
logic for this controller would proceed as follows. The first step would retrieve the 
sender address from the header of the message using a supplied utility function. 

20 Next, the logic would do a LOOKUP of the DECRYPTION-KEY for that sender. 
If one is found, the next step would apply the decryption utility function to the 
message body using the looked up key. Finally, a new message would be 
constructed having the same header information as the original but having the 
decrypted body in place of the original body, and this new message would be placed 
25 in the deliver queue (using the DELIVER act) for presentation to the client. If no 
decryption key were found for an incoming message’s sender, then the incoming 
message itself would simply be placed in the deliver queue (via the DELIVER act) 
without alteration. A similar scenario would apply to outgoing messages, using the 
ENCRYPTION-KEY state relation and the recipient field of the message, except 
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that multiple new (encrypted) messages may be created if the outgoing message has 
multiple recipients. 

To implement a digital signature verification feature, the controller 3 1 may 
be programmed, for example, to examine an incoming message (using utility 
5 functions provided by the framework or coded by hand) to see if it contains a digital 
signature block (a section of text having a particular predefined format). If it does 
have such a block, then the sender’s address is used as a key to look up in the state 
database a signature verification key, such as the decryption half of an asymmetric 
public/private key pair as is known in the art. If such a key is known, then a digital 
10 signature verification utility routine is applied to the message to determine whether 
the signature is valid. If it is, then, for example, a header line can be added that 
indicates “sender signature verified”. Otherwise, a line could be added that indicates 
“sender signature not verified”. Alternatively, a message with an unverified 
signature could be simply discarded by the proxy. If no key is known for a sender, a 
15 header line could be added to indicate “no sender key known”. 

To implement an autoresponse feature, the controller 3 1 may be 
programmed, for example, to examine incoming messages (using utility functions 
provided by the framework or coded by hand) to see if they have a particular 
structured command format. If an incoming message does not have this format, 

20 then it is simply delivered without change to the user’s mailbox. If it does have this 
format, then a prescribed action can be taken, such as formatting a new message 
having the requested document as its body and addressing it to the sender address of 
the original message. The user-supplied feature logic would then specify that the 
new message is to be sent to that address. 

25 As an example, suppose a user wishes to have his proxy automatically send 

out an electronic copy of any one of his published papers when any correspondent 
sends a request for one. And suppose a correspondent sends a message whose first 
body line is “SEND email-proxy.ps”. The feature logic would direct the controller 
3 1 to first examine this first line of the incoming message and detect adherence to 
30 the required format. It would then also check its state database to determine 
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whether “email-proxy.ps” is the name of a paper it has access to. If both checks 
succeed, it would create a new message, addressed to the sender of the original 
message, having a body consisting of the electronic format of the email-proxy.ps 
paper. It would finally place this new message in the send queue (using the SEND 
5 act) for subsequent transmission to the network. If either of the syntactic checks 
mentioned above fails, then the original message is simply placed unchanged in the 
deliver queue using the DELIVER act. 

A proxy 30 may be configured to perform a plurality of the features 
described herein (for example, autoresponse, digital signature verification, and 
10 encryption) on the same message if desired. 

Referring to Fig. 2, The SMTP (“simple mail transfer protocol”) server is 
coupled to the user’s electronic mail client 32 and to the outgoing queue 42. The 
SMTP server accepts outgoing messages from the user’s e-mail client 32 using an 
SMTP protocol, which is well known, and places them in the outgoing queue 42. 

15 The POP3 server 34 is coupled to the delivery queue 44 and to the user’s e-mail 
client 32. The POP3 server serves messages from the deliver queue 44, which is 
filled by the controller 3 1, to the user’s mail client 32 according to the well known 
POP3 (“post office protocol”) protocol. Both SMTP and POP3 are widely used on 
the Internet today. However, as new mail or electronic messaging protocols come 
20 into use, the SMTP server 33 and the POP3 server 34 may be replaced with the new 
protocols without affecting implementation of the other components of the proxy 
30. The SMTP proxy sender 38 and the POP3 proxy getter 36 may similarly be 
replaced. 

The SMTP proxy sender 38 is coupled to the send queue 48 and an SMTP 
25 network server 50 located on a network node remotely situated from the proxy 30. 
The SMTP proxy sender 38 monitors the send queue 48, which is filled by the 
controller 3 1, and uses the SMTP protocol to transmit these messages out to the 
network SMTP server 50 designated by the user’s configuration. The user’s 
configuration is stored in the database 39. POP3 proxy getter 36 is coupled to a 
30 POP3 netserver 52 located on a remote network node and to the incoming queue 
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46. The POP3 proxy getter 36 is a client for the network POP3 netserver 52 
designated by the user in the user configuration stored in database 39. The POP3 
proxy getter 36 gets messages from the POP3 netserver 52 and places them in the 
incoming queue 46 when prompted by a signal from the user’s mail client 32 which 
5 is forwarded by the POP3 proxy server 34. 

A user interface 40 may be added optionally. The user interface 40 is 
coupled to the controller 3 1 and allows the user direct control over the proxy 30. 

The user interface 40 may send and receive signals to and from the controller 31. 

Control or processing within the proxy 30 is event driven. When an 
10 electronic message arrives in a queue, the queues’ consumer process is awakened 
and the message stored. Storing a message into the queue may cause other 
processes to be awakened. For example, when a message arrives from the user’s 
client via the SMTP proxy server 33, the SMTP proxy server 33 places the message 
into the outgoing queue 42, which wakes up the controller 31. In response, the 
1 5 controller 3 1 may place one or more messages into the send queue 48. Storing of 

the message in the send queue 48 may wake up a process within the SMTP proxy 
sender 38, causing the SMTP proxy sender 3 8 to send one or more messages from 
the send queue 48 to the SMTP netserver 50. 

An extra signaling path is used to handle the on-demand nature of the POP3 
20 protocol. When the mail client probes the proxy POP3 server 34, the latter sends a 
signal to the POP3 proxy getter 36 and waits a short (configurable) period before 
checking the deliver queue 44. This wait allows the POP3 proxy getter 36 a chance 
to retrieve any new messages from the POP3 network server 52. The wait also 
allows the controller 31a chance to process any new messages retrieved, possibly 
25 placing one or more messages into the deliver queue 44. After the wait, the POP3 
server 34 forwards any messages in the deliver queue 44 to the mail client 32. 
Alternatively, the proxy 30 can be configured to have the POP3 proxy getter 36 
periodically check the network POP3 server 52 (even absent probes from the client), 
allowing proxy processing to proceed even when the user is not active at the mail 
30 client 32. 
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All of the message queues are persistent, which means that the data within 
each queue is stored with fixed memory backup such as on a disk drive or an 
EEPROM, so that in the event of a system crash the contents of the queues will not 
be lost. Messages are not deleted from one queue until the consumer process for 
5 the queue has finished processing and either has stored result messages into 

persistent queues (in the case of the controller) or confirmed successful completion 
of a protocol (message delivery by SMTP sender 38 or POP3 server 34). There is a 
small risk of duplicate message processing if a crash occurs after the result messages 
are written and before the input messages are deleted; however, this is arguably a 
10 better tradeoff than the opposite approach which allows the possibility of losing 

messages. 

The proxy 30 may be implemented using any software language including c, 
C++, PASCAL and COBOL. In a preferred embodiment, the proxy 30 is 
implemented as a stand-alone Java application in a reusable, object-oriented fashion 
15 within the client computer 10 . Typically, the proxy is started up once (for example 
when the machine 10 is booted). There are at least two startup options. The 
initialize-start option performs all initializations, including starting over from an 
empty state database. The warm-start option performs only enough initialization to 
resume processing where processing left off the last time the machine went down. 

20 Typically, the user will perform an initialize-start once and then warm-starts each 
boot thereafter. On initialization, the proxy application reads a configuration within 
the database 39 file that defines several parameters, such as the hostnames and ports 
of the SMTP and the POP3 network server 50 and 52 respectively and the location 
on the local disk where the persistent queues are to be stored. 

25 FIG. 3 illustrates a method of handling incoming electronic mail messages by 

the proxy 30. It also illustrates the interaction between the proxy 30 and the user’s 
mail client 32. In step 100, a user at the computer 10 issues a command to the mail 
client 32 to get any new mail present on the network 26. The user may indicate this 
with a keystroke on the keyboard 1 8, or with a click of a mouse coupled to the 
30 computer 10, or in any other convenient manner of indicating commands to the 
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computer 10. In response to the “get mail” command, in step 102 the user’s mail 
client 32 sends a request to the POP3 proxy server 34 within the proxy 30 to get 
any new mail which may have arrived at the proxy 30 from the network. In step 

103, the POP3 proxy server 34 forwards a signal for getting mail to the POP3 proxy 
5 getter 36. In response to the signal, the POP3 proxy getter 36 issues a request to 

the POP3 netserver 52 specified by the user’s configuration in the database 39. The 
request is for new mail. In addition, ,the proxy POP3 server 34 suspends in step 

104. In step 105, the POP3 proxy getter 36 receives from the POP3 netserver 52 
any new messages designated for a computer 10. In step 106, the POP3 getter 36 

10 sends received messages to the incoming queue 46 and to the controller 31. 

In step 107, the controller 31 processes the incoming event and places any 
messages received from the POP3 proxy getter 36 into the deliver queue 44 when 
the message is for the user’s e-mail client and the controller 3 1 updates its state via 
one or a collection of set commands to the database 39. Optionally, if the controller 
15 configuration so specifies, then no updates may be made via set. The controller 31 
may forego placing the received message into the deliver queue 44 depending on 
whether the controller 3 1 has been configured with advanced features. For 
example, if the controller is actively filtering incoming messages and the incoming 
message meets the filtering criteria, the message is terminated without being 
20 forwarded to the email client. In addition, if the controller 3 1 is implementing 

autoresponse, the controller 31 may, in response to receiving an incoming message, 
place a response message in the send queue 48 pursuant to the feature logic and 
configuration information in database 39. In general, arbitrary numbers of response 
messages may be placed in the send and deliver queues as prescribed by the user 
25 specified feature logic. In step 108, the proxy 30 optionally updates its user 

interface window with messages descriptive of the controller’s actions to inform the 
user of such actions. In step 109, the POP3 proxy server 34 comes out of its 
suspended state and checks the deliver queue 44 for any new messages which have 
arrived. If new messages have arrived, in step 109, the POP3 proxy server 34 
30 forwards the messages to the user’s mail client 32. In step 110, the mail client 
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presents new messages to a user. In step 111, the controller’s new state is saved to 
the database 39. In step 1 12, the SMTP sender 38 sends a message from the send 
queue 48 to a SMTP network server 50 which forwards the message to the new 
address determined by the feature logic, incoming message content, and 
5 configuration information in the send queue. Step 1 12 is optional and will not occur 
unless the feature logic dictates one or more response messages. 

FIG. 4 illustrates a method for sending a message from the mail client 
through the proxy 30 to a remote mail client on the network. In step 200, a user 
composes a message in the mail client 32. The user then initiates a “send operation” 
10 when the message has been completed. In step 202, the mail client 32 sends the 
message to the SMTP proxy server 33 within the proxy 30. In step 204, the SMTP 
proxy server 33 receives the message from the user’s mail client 32 and stores it into 
the outgoing queue 42. Also in step 204, the SMTP server 33 indicates to the 
controller 3 1 that the message has been stored in the outgoing queue 42. In step 
15 206, the controller 3 1 processes the outgoing event and places the message 

presently in the outgoing queue 42 into the send queue 48. If the controller 3 1 
dictates, no messages will be placed in the send queue 48. In addition, the 
controller 3 1 updates its state via one or more “set” commands and stores its state 
in the database 39. This is indicated in step 210. In step 208, the proxy optionally 
20 updates a user interface window within the display 20 to indicate the status of the 
controller. In step 212, the SMTP proxy sender 38 transmits the message from the 
send queue 48 to the SMTP netserver 50 over the network. The message is in turn 
further transmitted over the network 26 to the remote address specified in the e-mail 
header. Additionally, the controller 31 may be customized with a feature logic 
25 causing one or more messages to be placed in the deliver queue 44 when the 

outgoing message meets a predefined criteria. The predefined criteria may be based 
on content contained within the header or the body of the outgoing e-mail message, 
as well as the current state of the controller 31. For example, the controller state 
may change based on the time of day or other conditions as specified by the 
30 customizer. 
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FIG. 5 illustrates a method for processing user commands. In step 300, a 
user issues a command to the proxy 30 using the user interface window 40. In step 
302, the proxy user interface 40 receives and sends the command to the controller 
31. In step 304, the controller 3 1 processes the incoming command and places 
5 messages into the send 48 and/or deliver queue 44 when the command so requires. 
Additionally, the controller 3 1 may update its state within the database 39 when 
required. In step 306, the proxy 30 updates the proxy user interface 40 when the 
command has been processed. In step 308, the controller’s new state is saved. In 
step 3 10, the SMTP proxy sender 38 sends messages from the send queue 48 to the 
10 SMTP netserver over the network 26 when so required by the user issued 
command. 

In a preferred embodiment of the invention, the proxy 30 is customized, i.e. 
the desired feature logic is specified at compile time, by specializing three classes. 
The proxy class is the highest level such class. It has two overridable factory 
15 methods, make-controller and make-interface, which return instances of the other 
two user-specialized classes, controller and notifiable-window. (It is not required 
for customization to override make-interface, if no interface window is needed.) 
Another optional override is the init-from-config method which allows custom 
initializations to be performed, based On part) on information read from the 
20 configuration file within database 39. 

The preferred implementation provides an abstract controller class. In order 
to provide the desired feature logic at compile time, the customizer overrides the 
following five methods to implement the desired agent functionalities (all except the 
last have void return types): 

25 • handle_INIT 0 is called once at initialize-start only 

• handle_INCOMING (message, user). This method is called once for 
each message placed in the incoming queue 46 by the POP3 getter 36 
on behalf of a user. 
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• handle_OUTGOING (message, user). This method is called once for 
each message placed in the outgoing queue 42 by the SMTP proxy 
server 33 on behalf of a user. 

• handle_CQMMAND (command, user, arglist). This method may be 
called by the user interface 40 in response to a user gesture. It may 
also be called at initialization time if desired. 

• required_db_properties 0 - This method is called at initialization time 
to set up the proxy’s state database 39. 

The proxy callers of the “handle_x” methods are preferably synchronized, so 
that a programmer needn’t worry about concurrency. 

Each of these specialized methods may call effectors (acts), state database 
operations, and utility routines, which are provided by the framework code. Two 
effector methods are provided: MAIL (message) deposits a message into the send 
queue 48, and DELIVER (message) deposits a message into the deliver queue 44. 

A simple (persistent) database model is provided to record the state of the 
proxy .30 which is saved to disk and restored if the proxy is warm-started. An 
overloaded SET method allows setting values of database relations, which may be 1, 
2, or 3 placed relations in the current implementation. The required-db-properties 
method must return a list of db-property objects defining these relations. (This 
effectively defines the database schema.) An overloaded LOOKUP method is 
provided to read the database relations. For example, the 2-place relation 
“CORRESPONDENT-ADDRESS” could implement a simple address book relation 
useful for expanding aliases. Then SET (“CORRESPONDENT- ADDRESS”, 
“Bob”, “hall@research.att.com”) would set its values and LOOKUP 
(“CORRESPONDENT- ADDRESS”, “Bob”) would retrieve them. The proxy 
infrastructure makes these operations persistent, using database techniques that are 
well known in the art. 

A library of utility routines is provided for analyzing and synthesizing 
messages, such as extracting the message sender, canonicalizing e-mail addresses, or 
constructing a new message from sender, recipients, and text. The abstract data 
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type “message,” implemented using database techniques that are well known in the 
art, preferably hides the detail involved in making messages persistent, so that the 
user has a simple programming model with which to work. 

The abstract notifiable-window class, instances of which are typically user- 
5 interface windows, must implement the methods notify-set, notify-event, and notify- 
act which are called when (a) a state-db relation is modified (SET), (b) an event, 
such as INCOMING, OUTGOING, COMMAND, or IN IT, occurs and is handled, 
and (c) an act effector is invoked, such as MAIL or DELIVER. Thus, the user- 
interface 40 can react when any of these occur. Notifiable-window implementations 
10 may invoke INCOMING, OUTGOING, COMMAND, or INIT events during 

processing. Typically, this processing will accept user gestures, issue commands to 
the controller 3 1, and update a status display. 

In one embodiment of the invention, the proxy 30 is configured to implement 
a personal channel agent (PCA) which manages a user’s e-mail channels. The PCA 
15 performs address translation such as rewriting a header within the e-mail message 
and bookkeeping, for example, storing extended correspondent return addresses in 
the database 39 and correlating each return address to a particular piece of outgoing 
mail. The PCA also autonomously engages in a channel switching protocol with 
another PCA instance running somewhere else in the network. This protocol allows 
20 PCA’s, by sending structured e-mail messages to each other, to agree on which 
channel is to be used by the users at the PCA for addressing mail between them. 

In order to prohibit malicious users from impersonating a user, a 
configuration parameter may be included that restricts the SMTP server to accepting 
network connections only from the same host it is running on. This is necessitated 
25 by the insecurity of the SMTP protocol, which does no authentication. With this 
restriction, the proxy must run on the user’s machine. However, this restriction can 
be relaxed if the proxy is to run in the network, possibly by dispatching on the IP 
address of the incoming connection and connecting to a proxy devoted to users 
known to have that IP address. 
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To customize the proxy 20 to implement the PCA, I extended the proxy and 
controller classes, as described above, including implementing an interface window 
allowing the user to directly command the proxy to do various things. I had to write 
only 1700 lines of Java code custom for the PCA as compared to the 4600 lines in 
5 the preferred embodiment of the proxy framework. Thus, about 73% is reused 

framework code. Of course, reuse fraction is sensitive to message processing 
complexity of the task. 

In addition to the PCA implementation, the proxy 30 has other more general 
applications. For example, in another embodiment, the proxy 30 can be customized 
10 to make a general mail forwarder/gateway with arbitrary filtering, authentication, 
and autoresponse functionalities, by using only the SMTP half of the proxy 
(deactivating the POP3 portions by setting a switch). For example, by using only 
the SMTP proxy sender 38 and (an enhanced version of) the POP3 proxy server 
“half’ of the proxy 30, one can implement a multi-user host with filtering, 

15 autoresponse, etc, where multiple users can pick up their mail. One can also make 
this user-programmable with a user proxy communicating to the host via e-mail 
messages. The integrated SMTP interface allows the easy collaboration of multiple 
proxy-like agents distributed around the network. Thus, the proxy framework can 
be used as a platform for building distributed software agent applications. 

20 Although specific embodiments of the present invention have been disclosed, 

one of ordinary skill in the art will appreciate that changes can be made to those 
embodiments without departing from the spirit and scope of the invention. 
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CLAIMS 

What is claimed is: 

1. A system for processing electronic messages at a computer coupled to an 
5 electronic mail network, comprising: 

a communications port for exchanging electronic messages with an 
electronic mail network; 

an electronic mail client resident in a memory, 

a proxy application resident in the memory, the proxy application having a 
10 configurable controller specifying a manner of processing the electronic messages 

received from one of the electronic mail client and the communications port; and 
a processor coupled to the communications port and the memory, the 
processor executing the proxy application to process the electronic messages 
received from one of the electronic mail client and the communications port in 
1 5 accordance with a configuration of the controller. 

2. The system according to claim 1, further comprising: 

a first interface within the proxy application, the first interface coupling the 
electronic mail client to the proxy application pursuant to at least one network 
20 protocol. 

3. The system according to claim 2, wherein the first network interface includes 
a SMTP proxy server and a POP3 proxy server. 

25 4. The system according to claim 2, further comprising: 

a second interface within the proxy application, the second interface 
coupling the electronic mail network to the proxy application pursuant to the at least 
one network protocol. 
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5 . The system according to claim 4, wherein the second network interface 
includes a SMTP proxy sender and a POP3 proxy getter. 

6. The system according to claim 5, wherein the first network interface includes 
5 a SMTP proxy server and a POP3 proxy server. 

7. A system according to claim 1, wherein the controller is configured to 
terminate a first one of the electronic messages arriving at the proxy when the first 
electronic message meets a predetermined criteria. 

10 

8. A system according to claim 7, wherein the predetermined criteria is that the 
first electronic message includes a predetermined string. 

9. A system according to claim 8, wherein the first electronic message includes 
15 a subject field and the message is only terminated when the subject field of the 

message includes the predetermined string. 

10. A system according to claim 1, wherein the controller is configured to 
generate a new electronic message for transmission to the electronic mail network 

20 through the communications port in response to receiving one of the electronic 
messages having a predetermined criteria. 

11. A system according to claim 10, wherein the new electronic message is a 
text file stored in the memory. 

25 

12. A system according to claim 10, wherein the new electronic message is a 
binary file stored in the memory. 

13. A system according to claim 1, wherein the proxy application further 
30 comprises: 
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queues for storing the electronic messages in the memory. 

14. The system according to claim 13, wherein the queues store the electronic 
messages prior to the configurable controller routing the electronic messages. 

5 

15. The system according to claim 14, wherein the queues are persistent. 

16. The system according to claim 14, wherein the proxy application further 
comprises: 

10 interfaces for exchanging the electronic messages with the electronic mail 

client and the electronic mail network using a predetermined protocol. 

17. The system according to claim 16, wherein the predetermined protocol is the 
SMTP protocol. 

15 

18. The system according to claim 16, wherein the predetermined protocol is the 
POP3 protocol. 

19. The system according to claim 1, wherein the controller is configured to 
20 perform at least one of encrypting and decrypting the electronic message. 

20. The system according to claim 1, wherein the controller is configured to 
perform digital signature verification on the electronic messages. 

25 21 . A computer program product for implementing a proxy in a computer, 

comprising: 

a computer useable medium having computer program logic stored therein, 
wherein the computer program logic comprises: 

interfaces for enabling the proxy to receive electronic mail messages from an 
30 electronic mail client and an electronic mail network; 
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at least one queue coupled to the interfaces for enabling the proxy to store 
the electronic messages received from one of the interfaces; and 

a configurable controller for enabling the proxy to process the electronic 
messages received from one of the interfaces in accordance with a configuration of 
5 the controller. 

22. The computer program product according to claim 21, wherein the 
configuration of the controller causes the proxy to terminate a first one of the 
electronic messages received when it includes a predetermined string. 

10 

23. The computer program product according to claim 22, wherein the first 
electronic message received includes a subject field and the proxy only terminates 
the first electronic message when the subject field includes the predetermined string. 

15 24. The computer program product according to claim 21, wherein the 

configuration of the controller causes the proxy to generate a new electronic 
message for transmission to the electronic mail network. 

25. The computer program product according to claim 21, wherein the 
20 interfaces implement a predetermined protocol. 

26. The computer program product according to claim 25, wherein the 
predetermined protocol is the SMTP protocol. 

25 27. The computer program product according to claim 25, wherein the 

interfaces include a SMTP proxy server and a POP3 proxy server. 

28. The computer program product according to claim 27, wherein the 
interfaces further include a SMTP proxy sender and a POP3 proxy getter. 
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29. The computer program product according to claim 21, further comprising: 
a database, coupled to the controller, specifying the configuration of the 
controller. 

5 30. A method for processing electronic mail messages in a proxy application 

resident in a computer memory, the proxy application coupling an electronic mail 
client resident in the memory to an electronic mail network, comprising the steps of: 
receiving at the proxy application an electronic mail message from one of the 
electronic mail client and the electronic mail network; 

10 storing by the proxy application the electronic mail message; and 

processing the electronic mail message at the proxy in accordance with a 
configurable configuration. 

31. The method according to claim 30, further comprising the step of: 

1 5 terminating the electronic message when it includes a predetermined string. 

32. The method according to claim 31, wherein the electronic message includes 
a subject field and the terminating step only terminates the electronic message when 
the subject field includes the predetermined string. 

20 

33. The method according to claim 30, further comprising the step of: 
generating a new electronic message for transmission to the electronic mail 

network in response to receiving the electronic mail message. 

25 34. The method according to claim 30, further comprising the step of: 

storing in a database of the proxy the configurable configuration. 
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